(Just taking note) This package does not have the same deadline as others, review can wait until we need release automation.

It is tough because of all the system specific packages, I don't think I could set up a fork capable of the same release pattern.

I think releasing an alpha would be the best way to test, I will look into how napi-rs can be told to set the publish tag (if not possible it could be updated after releasing)

For SSDLC, currently, each package is built and released by napi-rs "automatically" in the sense that it uses the "npm/" directory to determine packages to release and that's all done as one step, are we going to have to "take over" that step so we can insert signing? maybe it would be easier to test once we own that part.

Alpha sounds good. But are you suggesting we just hold off on this PR until we tackle SSDLC for it? That's also fine with me, I'll just take my face off of it on the Kanban board.

For SSDLC, currently, each package is built and released by napi-rs "automatically" in the sense that it uses the "npm/" directory to determine packages to release and that's all done as one step, are we going to have to "take over" that step so we can insert signing? maybe it would be easier to test once we own that part.

I don't think so - there's already a step in the existing CI that ls -R npm, so we have access to all the npm packages. We can sign the contents of each package from that directory

SSDLC work will have larger changes to this package in the near future, we will revisit release automation then and port over the work from kerberos and mongodb-client-encyrption.